Most modern Ethernet forwarding elements (e.g., switches and routers) include flow-tables (typically built from TCAMs or Ternary Content Addressable Memories) that run at line-rate to implement firewalls, NAT (network address translation), and QoS (quality of service), and to collect statistics. While flow-tables of different vendors may be different, OpenFlow exploits a common set of functions that run in many switches and routers.
OpenFlow provides an open protocol to program flowtables in different forwarding elements (e.g., switches and routers). A network administrator, for example, can partition traffic into production and research flows, and/or researchers can control their own flows by choosing the routes their packets follow and the processing they receive. In this way, researchers can try new routing protocols, security models, addressing schemes, and even alternatives to IP (Internet Protocol). On the same network, the production traffic may be isolated and processed conventionally.
The datapath of an OpenFlow forwarding element (e.g., switch) may include a flow table, and an action associated with each flow entry included in the flow table. The set of actions supported by an OpenFlow forwarding element may be extensible. For high-performance and low-cost, the datapath may have a carefully prescribed degree of flexibility, which may mean forgoing the ability to specify arbitrary handling of each packet and seeking a more limited, but still useful, range of actions.
An OpenFlow forwarding element may include a flow table having a plurality of flow entries (with an action associated with each flow entry) to tell the forwarding element how to process the respective flow, a secure channel that connects the switch to a remote OpenFlow controller (allowing commands and packets to be sent between the controller and the forwarding element using the OpenFlow Protocol (which provides an open and standard way for a controller to communicate with a forwarding element). By specifying a standard interface (the OpenFlow Protocol) through which entries in the forwarding element Flow Table can be defined using an external controller, researchers may not need to individually program OpenFlow forwarding elements.
An OpenFlow forwarding element may include one or more flow tables and a group table (which may perform packet lookups and forwarding) and an OpenFlow channel to an external OpenFlow controller. The OpenFlow controller manages the forwarding element via the OpenFlow protocol. Using this protocol, the controller can add, update, and delete flow entries, both reactively (in response to packets received at the forwarding element) and proactively (e.g., to program flow tables of a new forwarding element).
Each flow table in the forwarding element may include a set of flow entries. Each flow entry may include matched fields, counters, and a set of instructions to apply to matching packets.
Matching at a forwarding element may start at a first flow table and may continue to additional flow tables of the forwarding element. Flow entries match data packets in priority order, with the first matching entry in each table being used. If a matching entry is found for a data packet in a flow table, the instructions associated with the specific flow entry are executed for the data packet. If no match is found for the data packet in a flow table, the outcome may depend on forwarding element configuration. The data packet may be forwarded to the controller over the OpenFlow channel, the data packet may be dropped, or attempts to match the data packet may continue to a next flow table of the forwarding element.
Instructions associated with each flow entry describe data packet forwarding, data packet modification, group table processing, and pipeline processing. Pipeline processing instructions allow data packets to be sent to subsequent tables for further processing and allow information (e.g., in the form of metadata) to be communicated between tables. Table pipeline processing may stop when the instruction set associated with a matching flow entry does not specify a next table. At this point, the data packet may usually be modified and forwarded.
Flow entries may forward respective data packets to a port. This is usually a physical port, but it may also be a virtual port defined by the switch or a reserved virtual port defined by the OpenFlow switch specification. Reserved virtual ports may specify generic forwarding actions such as sending to the controller, flooding, or forwarding using non-OpenFlow methods, such as “normal” switch processing, while switch-defined virtual ports may specify link aggregation groups, tunnels or loopback interfaces.
Flow entries may also point to a group, which specifies additional processing. Groups represent sets of actions for flooding, as well as more complex forwarding semantics (e.g., multipath, fast reroute, and link aggregation). As a general layer of indirection, groups also enable multiple flows to forward to a single identifier (e.g., IP forwarding to a common next hop). This abstraction may allow common output actions across flows to be changed efficiently.
A group table may include group entries, with each group entry including a list of action buckets with specific semantics dependent on group type. The actions in one or more action buckets are applied to data packets sent to the group.
OpenFlow forwarding elements (e.g., switches and/or routers), controllers, and protocols are discussed, for example, in “OpenFlow Switch Specification,” Version 1.1.0 Implemented (Wire Protocol 0x02), Feb. 28, 2011, and in the reference by McKeown et al. entitled “OpenFlow: Enabling Innovation In Campus Networks,” Mar. 14, 2008. The disclosures of both of the above referenced documents are hereby incorporated herein in their entireties by reference.
The OpenFlow channel is an interface that connects an OpenFlow forwarding element with a controller over an OpenFlow interface. The interface itself may be implementation specific, and it may be implemented using a TCP (Transmission Control Protocol) connection or a SCTP (Stream Control Transmission Protocol) connection. Moreover, TLS (Transport Layer Security) may be used to send messages that are encrypted by the controller and decrypted by the forwarding element.
Control for a network of OpenFlow forwarding elements may be implemented using a cluster of OpenFlow controllers, and each forwarding element may use a known IP (Internet Protocol) address of one of the controllers to connect with the addressed controller according to a configuration protocol. In some implementations, a non-standard configuration channel may be used to configure a connection between a forwarding element and a respective controller. In other implementations, a forwarding element may be programmed with a list of IP addresses for controllers to connect with, and the forwarding element may sequentially attempt to connect to a controller using each controller address in the list until a successful connection with a controller is made.
Conventionally, a connection between an OpenFlow forwarding element and an OpenFlow controller may be set up responsive to the forwarding element initiating a connection socket with the controller and requesting the connection. The controller may then decide whether to allow the connection or not. If the controller accepts the connection, the connection may be completed and messages between the controller and the forwarding element may be transmitted over the resulting OpenFlow channel. If the controller does not accept the connection, the connection socket may be terminated.
Conventionally, once a connection is established between an OpenFlow forwarding element and an OpenFlow controller, the OpenFlow controller may only be able to drop the connection by ignoring an ECHO-REQUEST communication from the forwarding element (i.e., by not transmitting an ECHO-REPLY in response to the ECHO-REQUEST) thereby allowing the connection to timeout. Dropping a connection in this manner, however, may be dependent on a timeout value configuration of the OpenFlow Request-Reply protocol. Stated in other words, once the controller decides to drop a connection with a forwarding element, the connection may not actually be dropped until after a next ECHO-REQUEST has been transmitted by the forwarding element and a timeout period has passed after the ECHO-REQUEST without transmitting an ECHO-REPLY.
Moreover, conventional mechanisms to connect an OpenFlow forwarding element with an OpenFlow switch may be limited. A complex configuration channel may be adopted, for example, to configure an OpenFlow forwarding element to connect with a controller from a list of controllers known to the forwarding element. Using such a known list of controllers, however, may make it difficult for a forwarding element to connect to an unknown controller (e.g., a controller added to the cluster after provisioning the list). In addition, it may be difficult to share the load of network forwarding elements in the forwarding plane among controllers in the control plane.
In some controller implementations, one controller of a cluster of controllers may be designated as a master controller of the cluster, and only the master controller may be allowed to accept OpenFlow connections from network forwarding elements. If another controller is later designated among the controllers as the master controller or if the master controller fails in a conventional arrangement, the forwarding element may be delayed in connecting to a new master controller and/or the forwarding element may be unable to connect to the new master element.
Accordingly, there continues to exist a need in the art for improved operations in networks including forwarding elements and controllers.